Implement immediate-abort by hooking #[rustc_panic_entrypoint] and lint for functions that look like a panic entrypoint by saethlin · Pull Request #150497 · rust-lang/rust

saethlin · 2025-12-30T01:51:23Z

There are a handful of functions, mostly in core, which have a mess of attributes on them which try to ensure that they compile down to just intrinsics::abort() when cfg(panic = "immediate-abort"), and otherwise are outlined. These functions now all get #[rustc_panic_entrypoint] which makes the functions #[cold], #[inline(never)], and #[optimize(size)]. But when immediate-abort is enabled, these functions are #[inline].

And since these functions are now all known to the compiler, when immediate-abort is enabled, both their bodies and calls to them are directly replaced intrinsics::abort(). Replacing both body and calls means that we rely much less on optimization to make immediate-abort do its job, but if for some godforsaken reason you are indirectly calling a panic entrypoint, that will still immediately abort.

There is a fair bit of inconsistency in what attributes are on panic entrypoints, only some have #[optimize(size)] and about half have #[inline(never)]. The single attribute makes sure they are all treated the same. (I am making an informed guess that the inconsistency was accidental, and mostly not impactful)

This PR also adds an allow-by-default lint, missing_panic_entrypoint which looks for diverging functions that do not have one of #[rustc_panic_entrypoint] or #[inline]. Panic wrappers sometimes have #[inline] because they are the const fn for a const_eval_select, so adding #[inline] ensures that monomorphization doesn't eagerly codegen a useless copy of them.

TODO:
Make the way cg_ssa patches out diverging calls check for the entry point attr

bors · 2025-12-30T09:30:10Z

☔ The latest upstream changes (presumably #150386) made this pull request unmergeable. Please resolve the merge conflicts.

compiler/rustc_codegen_ssa/src/mir/block.rs

bjorn3 · 2025-12-30T11:44:23Z

Should #[rustc_panic_entrypoint] imply #[cold] #[inline(never)] #[track_caller]? Is that even easy to implement?

Should be possible to check #[rustc_panic_entrypoint] when computing the CodegenFnAttrs.

saethlin · 2025-12-30T19:54:55Z

Should be possible to check #[rustc_panic_entrypoint] when computing the CodegenFnAttrs.

Yep. But it turns out #[track_caller] is fiddly because codegen backends have assumed that for example panic_nounwind doesn't have the extra location argument and threading through what location to pass them is fiddly. Maybe something to fiddle with in a second PR. It's not clear to me that the entrypoints that don't have track_caller are actually good. But that might have perf implications on normal builds, which I'd rather minimize.

saethlin · 2025-12-31T01:27:08Z

@bors try @rust-timer queue

Implement immediate-abort by hooking #[rustc_panic_entrypoint] and lint for functions that look like a panic entrypoint

rust-bors · 2025-12-31T03:51:18Z

☀️ Try build successful (CI)
Build commit: 0de2b26 (0de2b267a76559681f8e610c347a4a016cdb10b5, parent: 0e8999942552691afc20495af6227eca8ab0af05)

rust-timer · 2025-12-31T04:32:36Z

Finished benchmarking commit (0de2b26): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 0.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.9%	[0.9%, 0.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.0%, secondary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.1%]	4
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	1
All ❌✅ (primary)	0.0%	[0.0%, 0.1%]	4

Bootstrap: 480.336s -> 480.598s (0.05%)
Artifact size: 390.83 MiB -> 390.83 MiB (0.00%)

Noratrieb · 2025-12-31T10:51:00Z

compiler/rustc_lint/src/builtin.rs

    }
 }
+
+declare_lint! {


This should be an internal lint

Should it? Internal lints are enabled on the compiler crates, and I only want this on the standard library.

saethlin · 2025-12-31T20:08:59Z

I'm lost. How did trying to add an internal lint (which uses completely different macros from adding a builtin lint??) remove another lint?

	warning: unknown lint: `rustc::default_hash_types`
	 --> compiler/rustc_fluent_macro/src/lib.rs:2:10
	  |
	2 | #![allow(rustc::default_hash_types)]
	  |          ^^^^^^^^^^^^^^^^^^^^^^^^^

rust-bors · 2026-01-03T04:07:02Z

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2026-01-03T05:06:07Z

☔ The latest upstream changes (presumably #150628) made this pull request unmergeable. Please resolve the merge conflicts.